Conventional art relating to a redundant connecting method between a plurality of packet rings will be described.
Conventionally, in a network adopting the Ethernet (registered trademark), there is a case where an Ethernet switch is connected with redundancy so as not to be affected by failures in links or nodes. In the case of involving such redundancy, the Spanning Tree Protocol is used for constructing a topology not causing a loop. The Spanning Tree Protocol is a protocol which always maintains a loop-free logical topology even if a topology change is caused in association with operation or a topology change is caused by any failure. When a loop is caused in a network adopting the Ethernet (registered trademark), problems such as multiple arrival of packets and pressure on band due to an increase in packets are caused. Further, an upper layer application may be inversely affected by unconvergence of FDB (forwarding database), or system down may be caused. In order to prevent such problems, it is necessary to prevent a loop from being caused in a network adopting the Ethernet (registered trademark). By applying the Spanning Tree Protocol, a loop-free logical topology can be constructed and maintained, which enables to prevent problems caused by a loop as described above.
In the Spanning Tree Protocol, when a failure occurs in links or nodes, reconstruction of logical topology starts in all switches, and data transmission becomes impossible until the reconstruction is completed. It may take several minutes for topology convergence, depending on the scale of the network.
Ring-type redundancy protocols include EAPS (Ethernet Automatic Protection Switching), MRP (Metro Ring Protocol), and MMRP (Multi Master Ring Protocol). The ring-type redundancy protocol such as EAPS, MRP or MMRP is a simple and inexpensive system in which Ethernet switches are arranged in a ring, and a Hello packet is flown to the ring so as to monitor link shutdown to thereby control a blocking port so as not to cause a loop.
In each of the ring-type redundancy protocols, monitoring of a link failure is performed with a Hello packet, so the failure recovery time is determined depending on the transmission interval time of the Hello packet. This generally requires a failure recovery time of not longer than several seconds. Further, in the normal operating state, one port is always in a blocking state, so the shortest path transfer cannot be provided, causing low usability of the ring band.
Further, in the network redundancy in the layer 3, a routing protocol in the router is used generally. RIP (Routing Information Protocol) and OSPF (Open Shortest Path First), generally used, recognize a topology change in association with operation or a topology change caused by a failure, and recalculate a routing table to thereby maintain communications in a new topology.
Processing from detection of a change in the network topology by these routine protocols up to reconstruction is generally performed as processing by software. Therefore, the time required from detection of topology change up to the completion of reconstruction may take several minutes depending on the scale of the network.
Further, the packet ring network includes RPR (Resilient Packet Ring). RPR is standardized by IEEE802.17. RPR is a MAC layer protocol providing an access to a ring-shape transmission medium, providing a high-speed failure recovery in the carrier class, effective utilization of the network band, and shortest path transfer.
FIG. 37 is an illustration showing an exemplary network configuration of RPR. As shown in FIG. 37, a packet ring included in the RPR network includes two ringlets 701 and 702 which transfer a packet in opposite directions to each other. Further, in the packet ring, a plurality of nodes are connected to be in a ring shape. FIG. 37 shows a case where four nodes 703a, 703b, 703c and 703d are connected in the packet ring. To each node on the packet ring, an RPR MAC address is given respectively. When the network is constructed, a control packet is exchanged between nodes, and each node collects information about the number of hops between nodes and acquires topology information of the network.
Further, to each node on the packet ring, a user terminal may be connected. The example shown in FIG. 37 illustrates a case where a user terminal 704a is connected to the node 703a, and a user terminal 704b is connected to the node 703b. 
FIG. 38 illustrates an RPR packet format. When a user terminal transmits a packet to a node, it transmits a user data packet 711. The user data packet 711 includes an MAC address (MAC DA) 712 of the destination user terminal of the user data packet, an MAC address (MAC SA) 713 of the source user terminal of the user data packet, transmission data 714, and an FCS (Frame Check Sequence) 715. When a node receives a user data packet from a user terminal, the node encapsulates the user data packet to thereby generate an RPR packet 721, and transmits/receives the RPR packet 721 between nodes. The user data packet 711 is encapsulated, and in the RPR packet 721, it is stored as data 726. Further, the RPR packet 721 includes the MAC address of the destination node (RPR MAC DA) 724, the MAC address of the source node (RPR MAC SA) 725, a Base Control field 723, a TTL (Time To Live) field 722, and an FCS 727. The Base Control field 723 includes information designating the ringlet used for transfer, and identification information for identifying the packet type of the control packet and the like. The TTL field 722 is used to prevent a packet from endlessly rotating the ring. The detail of the RPR packet format is described in Non-Patent Document 1.
Operations of transmitting, receiving and transferring the RPR packet at each node on the ring will be described below. First, the case of a unicast packet will be described. Each node receives an RPR packet transferred on the ring, and if the RPR MAC DA of the RPR packet coincides with the RPR MAC address of itself, the node eliminates the RPR packet from the ring. If the RPR MAC DA of the received RPR packet differs from the RPR MAC address of itself, the node decrements the TTL and then retransmits the RPR packet to the same ringlet from which the node received the packet. When the source node receives the unicast packet transmitted by the source node itself, the source node eliminates the unicast packet from the ring. Further, when the TTL becomes 0, each node eliminates the RPR packet from the ring.
In the case of a broadcast packet, each node first decrements the TTL of the received broadcast packet, and then transfers it to the next node. When the source node of the broadcast packet receives the broadcast packet transmitted by itself, the source node eliminates the broadcast packet from the ring. Further, when the TTL becomes 0, each node eliminates the RPR packet from the ring.
Note that control packets to be used for band control, topology detection, failure recovery and the like have no relationship with the present invention, so their detailed description is omitted.
Next, in the RPR network shown in FIG. 37, an operation of transmitting data from the user terminal 704a, connected to the node 703a, to the user terminal 704b, connected to the node 703b, will be described. Each node studies the MAC SA 713 (see FIG. 38) of the source user terminal encapsulated in the received RPR packet and the source RPR MAC SA 725 (see FIG. 38) while corresponding them with each other, and holds an RPR MAC address database, that is, an FDB, in which the MAC address of the user terminal is used as the search key. When the user terminal 704a transmits data (user data packet) to the ring, the node 703a receives the user data packet. The node 703a searches the FDB by using the MAC DA 712 (see FIG. 38) in the received user data packet as the search key, and sets the result as RPR MAC DA 724 (MAC address of the destination node, see FIG. 38). Further, the node 703a sets the MAC address of itself as RPR MAC SA 725 (MAC address of the source node, see FIG. 38). Then, the node 703a encapsulates the user data packet received from the user terminal 704a. Further, the node 703a searches the topology database, selects a ringlet providing the shortest path from the source node to the destination node and sets the TTL value, and transmits the RPR packet to the ring.
Further, as a result of searching the FDB, if correspondence between the MAC address of the destination user terminal and the RPR MAC address corresponding to the MAC address has not been studied, the node 703a performs flooding. To the RPR MAC DA of the RPR packet transmitted by flooding, a broadcast address is set, and the RPR packet is received by all nodes on the ring. Further, as a result of the flooding, a user data packet transmitted by the user terminal 704a is received by the destination user terminal 704b. Then, the user terminal 704b sends a reply to the user terminal 704a. When replying, the user terminal 704b is the source of the user data packet, and the user terminal 704a is the destination. Further, the node 703b is the source of the RPR packet. When a reply from the user terminal 704b is sent, the correspondence between the MAC address of the user terminal 704b and the RPR MAC address of the user terminal 703b is studied in the node 703a. Accordingly, when the user terminal 704a transmits the user data packet to the user terminal 704b again, the node 703a searches for the RPR MAC address of the node 703b by using the MAC DA 712 included in the user data packet as the key, whereby it can perform unicast transfer by using the search result as the RPR MAC DA 724.
Next, referring to FIG. 39, the protective operation of the RPR will be described. In the IEEE802.17, a steering mode and a lap mode are defined as the protective operations when a failure occurs. The steering mode is defined as a mandatory function, and the lap mode is defined as an optional function. The steering mode and the lap mode are also introduced in Patent Document 1 for example.
FIG. 39(a) shows the network operation in a normal state. FIG. 39(a) shows a state where a packet is transferred from the node 803a to the node 803b on the ringlet 801.
FIG. 39(b) shows the operation in the steering mode. As shown in FIG. 39(b), when a failure point 804 is caused, all nodes in the ring acquire the positional information of the failure point 804. That is, the nodes 803c and 803d connected to the link causing the failure point 804 notify all other nodes of the positional information of the failure point 804. As a result, each node recognizes the position of the failure point 804. Then, in transmitting a unicast packet, the source node selects a ringlet not including the failure point 804 between it and the destination node of the RPR packet, and transmits the unicast packet. For example, when the node 803a transmits a unicast packet to the node 803b, it changes the ringlet for transmitting the unicast packet from the ringlet 801 to the ringlet 802 since it recognizes the position of the failure point 804, so it transfers the packet to the node 803b. Further, in the case of transmitting a broadcast packet, the node 803a selects both ringlets 801 and 802, and sends the broadcast packet to each of the ringlets 801 and 802. As a result, the broadcast packet is transmitted to each node in the ring.
FIG. 39(c) shows the operation in the lap mode. In the lap mode, the source node selects the same ringlet as that in the normal state and transmits an RPR packet. For example, when the node 803a transmits an RPR packet to the node 803b, the node 803a selects the ringlet 801 same as the normal state (see FIG. 39(a)) and transmits the RPR packet. When the node 803c, which detects the failure since it is connected with the link causing the failure point 804, receives the RPR packet, it selects another ringlet 802 different from the ringlet 801 from which the packet was transmitted, and transfers the RPR packet by using the ringlet 802. That is, the node 803c transfers the RPR packet to the side where the failure point 804 does not exist. The packet is transferred on the ringlet 802 up to the node 803d which detects the failure since it is connected to the link causing the failure point 804. The node 803d also selects a ringlet other than that from which the packet is transmitted, and transfers the RPR packet using the ringlet. As a result, the destination node 803b receives the RPR packet. Further, methods of flooding a broadcast packet to a ring include a method of sending arbitrary one ringlet by the source node, and a method of sending a broadcast packet to both ringlets by the source node and transferring up to the arrival point previously set on the ring in order to prevent multiple transfer (bidirectional flooding). Note that the arrival point of a packet previously set on the ring for preventing multiple transfer is called a cleave point. In the case of bidirectional flooding, TTP calculation method is required to be changed in order to transfer a packet to all nodes and prevent duplicate arrival, depending on whether the number of nodes in the ring being odd number or even number. However, the TTL calculation method has a little relationship with the present invention, so it is not described.
Although description has been given with the example that a failure occurs in a link, the protective operation in the case that a failure occurs in a node is same as that of the case where a failure occurs in a link.
FIG. 40 is an illustration showing an example of a network system in which two rings are connected redundantly. In the network system shown in FIG. 40, two rings 901 and 902 are connected with two links 903 and 904. The link 903 connects a node 901a in the ring 901 and a node 902a in the ring 902. Similarly, the link 904 connects a node 901b in the ring 901 and a node 902b in the ring 902. Further, the ring 901 has ringlets 910a and 910b. Similarly, the ring 902 has ringlets 920a and 920b. In the network system shown in FIG. 40, a pair of rings 901 and 902 are connected with a plurality of links 903 and 904. Further, the ring 901 includes a node 901x other than the inter-ring connecting nodes 901a and 901b connected with the ring 902. Similarly, the ring 902 includes a node (not shown) other than the inter-ring connecting node 902a and 902b connected with the ring 901. It is assumed that a different RPR MAC address is assigned to each node.
A broadcast packet transmitted from a node on the ring 901 is transferred to the ring 902 via the inter-ring connecting node 901a, the link 903, and the inter-ring connecting node 902a. Similarly, the packet is transferred to the ring 902 via the inter-ring connecting node 901b, the link 904, and the inter-ring connecting node 902b. The nodes 902a and 902b in the ring 902 of the receiving side perform flooding, respectively. This causes a problem that one node receives the packet in a duplicate manner. If a multiple reception of packets in one node is caused, the upper layer application is adversely affected.
Further, there is another problem that a broadcast packet reciprocates between the ring 901 and the ring 902, causing a phenomenon that the packet will not be eliminated from the ring forever. This phenomenon is called a broadcast stream. Hereinafter, generating process of a broadcast stream will be described with reference to FIG. 40.
A broadcast packet transmitted from the node 901x goes around the ring 901, and is received by the inter-ring connecting node 901a. The inter-ring connecting node 901a receives the packet from the ring, and transfers it to the inter-ring connection node 902a via the link 903. Further, the inter-ring connecting node 901a also transfers the packet to the next node 901b on the ring 901. In the inter-ring transfer from the ring 901 to the ring 902, the inter-ring connection node 901a ends the RPR MAC address of the packet. Then, the inter-ring connecting node 902a transfers the broadcast packet in which the RPR MAC address of the node 902a itself is used as the RPR MAC SA, and the packet is received by the inter-ring connecting node 902b. 
The inter-ring connecting node 902b transfers the packet to the inter-ring connecting node 901b via the link 904. Further, the inter-ring connecting node 902b transfers the packet to the next node 902a on the ring 902. The node 902a eliminates the broadcast packet transmitted by itself and received from the node 902b after rotation, from the ring 902. In the inter-ring transfer from the ring 902 to the ring 901, the inter-ring connecting node 902b ends the RPR MAC address of the packet. Then, the inter-ring connecting node 901b transmits the broadcast packet by using the RPR MAC address of the node 901b itself as the RPR MAC SA. The broadcast packet is received by the inter-ring connecting node 901a. Thereafter, the nodes 901a, 902a, 902b and 901b repeat the same operation, so a phenomenon that the broadcast packet will not be eliminated from the rings 901 and 902 forever (broadcast stream) is caused. This results in the network band being consumed unnecessarily.
Patent Document 2 discloses art to solve the problems described above (multiple reception of packets and broadcast stream). The packet ring network system described in Patent Document 2 includes first and second connecting nodes for connecting first and second packet rings to thereby make the connection between the rings redundant. In a normal state, only one of the nodes connecting the rings transmits a packet between the rings. As a result, there is only one relay for a broadcast packet, so an adverse effect on the upper layer application caused due to multiple transfer of the same packet and a system down caused by a broadcast stream can be prevented. Further, in the packet ring network system described in Patent Document 2, two nodes connecting the rings are allowed to be active (a state of transferring the packet), depending on the state of failure. Consequently, a flexible network operating mode becomes possible even if a failure occurs in the ring. Note that in the network system described in Patent Document 2, a node which becomes active eliminates the MAC address of the node, which was active, from the FDB with respect to the respective nodes in the ring. This prompts restudy of bridge without waiting for age out, enabling early recovery of communications.
Note that as the art relating to RPR, Non-Patent Document 2 describes a pulse through transfer function and bidirectional flooding.
Patent Document 1: Japanese Patent Application Laid-Open No. 2004-242194 (paragraphs 0004, 0012)
Patent Document 2: Japanese Patent Application Laid-Open No. 2003-258822 (paragraphs 0015-0085)
Non-Patent Document 1: IEEE Std 802.17-2004 “PART17: RPR ACCESS METHOD AND PHYSICAL LAYER SPECIFICATION”, “9. Frame format”
Non-Patent Document 2: IEEE802.17 (Draft3.3), p. 117, p. 60, p. 190